home *** CD-ROM | disk | FTP | other *** search
/ The CICA Windows Explosion! / The CICA Windows Explosion! - Disc 2.iso / programr / rtx2000.zip / rtx2000 / fc / fc.doc next >
Text File  |  1993-06-08  |  45KB  |  1,531 lines
  1.     fc - A Public Domain FORTH Cross Compiler for the RTX2000                 
  2.  
  3.                          Microcontroller
  4.  
  5.  
  6.  
  7.                             Version 1.14
  8.  
  9.  
  10.  
  11.     
  12.  
  13.  
  14.  
  15.  
  16.  
  17. fc is a FORTH compiler that generates machine code for the 
  18. Harris RTX2000 microcontroller chip.  fc accepts text files generated 
  19. by a text editor and produces optimized object code files for the 
  20. RTX2000.  fc has options for generating annotated object code listings 
  21. and cross reference files which can be incorporated into other 
  22. programs to link variable and word definitions.  fc can also be used 
  23. to produce code for the Harris RTX2010 and RTX2010 specific 
  24. instructions can be added using the #macro and ucode features.  
  25.  
  26.  
  27.  
  28. fc currently runs on an AMIGA or IBM PC compatible computer 
  29. with either a hard disk or ram disk.  fc has been tested using 
  30. AmigaDos 1.3 and MS-DOS 5.0 but, may work with other versions of 
  31. either operating system.   
  32.  
  33.  
  34.  
  35. fc was made possible by the Public Domain version of Berkely 
  36. yacc available on Fred Fish Disk #419.  Many thanks to Bob Corbett and  
  37. those who helped make this public domain version of yacc.
  38.  
  39.  
  40.  
  41. I would also like to thank John Goldsten and Augie Mattheiss 
  42. for their help in debugging and testing the compiler.  John, Augie, 
  43. and the author have developed several programs using the MS-DOS and 
  44. AMIGA versions of the compiler that have been successfully executed on 
  45. RTX2000 target systems.  We normally use the -o output option or the -
  46. e output option for EPROMs.  The EPROM output option has been 
  47. successfully used with a DATAIO UNISITE programmer.  
  48.  
  49.  
  50.  
  51. fc is a Public Domain program so no fee should be charged for 
  52. distribution except for a possible media charge.  fc was developed 
  53. using Aztec C for AMIGA version 3.6A with the default 16 bit integers.  
  54. fc has been ported to MS-DOS and the MS-DOS executable is included in 
  55. the distribution.  That version is identical to the AMIGA version 
  56. except for some details pertaining to memory allocation and the naming 
  57. of some of the source file names.  An experimental Macintosh version 
  58. may also be included in the distribution and it will require MPW. 
  59.  
  60.  
  61.  
  62. fc is currently being used for software development future 
  63. revisions are likely.  We already have had several months experience 
  64. producing and executing code generated by fc.  However, fc is offered 
  65. "as is" and will not necessarily be supported.  Anyone wishing to 
  66. develop large programs for the RTX2000 or RTX2010 may wish to look 
  67. into other development systems or cross compilers from one of the 
  68. several vendors marketing them.  
  69.  
  70.  
  71.  
  72. A test file is included with the distribution to demonstrate 
  73. code production of the compiler.  This output has been checked against 
  74. the instruction set listed in the Harris RTX2000 Programmer's 
  75. Reference Manual.  However, users should check the code production in 
  76. a disassembly output should they run into any really puzzling problems 
  77. when debugging their programs.  We have developed several programs up 
  78. to 4K bytes long and have not run into any code production problems 
  79. for the last couple of months.  
  80.  
  81.  
  82.  
  83.  
  84.  
  85. Background
  86.  
  87.  
  88.  
  89. The RTX2000 microcontroller is a 16 bit microprocessor 
  90. architectureally designed for executing the FORTH language.  The 
  91. RTX2000 instruction set corresponds to FORTH primitive words (like 
  92. SWAP, DROP, @, !, etc) and combinations of primitive words which, in 
  93. some cases, allow several FORTH instructions to be encoded into a 
  94. single RTX2000 instruction.  All RTX2000 instructions execute in one 
  95. or two cycles and are sixteen or thirty-two bits long.  It is common 
  96. to run the RTX2000 at rates of 8MHz to 10MHz making it fast for real 
  97. time control applications.  
  98.  
  99.  
  100.  
  101. The RTX2000 chip includes two onboard stacks (256 deep), one is 
  102. used for parameters and the other is used mainly for subroutine 
  103. returns.  This allows stack operations like SWAP, DROP, etc, to be 
  104. performed without an external memory access.  Likewise subroutine 
  105. returns are done using the onboard return stack making subroutine 
  106. overhead quite low.  In fact, most RTX2000 instructions can be coded 
  107. to perform a return as part of the instruction so, returns often don't 
  108. even require any extra code.
  109.  
  110.  
  111.  
  112. The RTX2000 has several onboard peripherals, including three 
  113. timer/counters and an interrupt controller. For more information on 
  114. the RTX2000, consult the data sheet from Harris semiconductor.  
  115. Potential users are strongly advised to investigate Harris' plan for 
  116. future support of the RTX2000 family before committing to the chip.  
  117.  
  118.  
  119.  
  120. fc should also be compatible with the Harris RTX2010RH which is 
  121. sold as an ASIC.  The RTX2010RH features higher radiation tolerance 
  122. then the RTX2000, a barrel shifter, and a multiply accumulate circuit.  
  123. Support for RTX2010 specific instructions can be added by using the 
  124. macro capability of fc.   
  125.  
  126.  
  127.  
  128.  
  129.  
  130. Running fc 
  131.  
  132.  
  133.  
  134. fc is invoked from the CLI (AMIGA) or MS-DOS by typing:
  135.  
  136.  
  137.  
  138. fc {-lreoxsd} {iaaa} {-tbbb} filename   
  139.  
  140.  
  141.  
  142. fc recognizes nine command line options - l, x, e, o, r, s, d, i and 
  143. t.  The l, x, s, d, i, and t options can be used in any combination 
  144. along with one of the other three options.  All options must proceed 
  145. the source file name.  The source file name is used as the base name 
  146. for generating output files.  If the source file has an extension, the 
  147. extension is removed when forming the output file names.  
  148.  
  149.  
  150.  
  151. The l option writes a disassembled listing of the program into 
  152. a file named filename.lst.  The e option produces two EPROM output 
  153. files named filename.low and filename.hi instead of the default object 
  154. code output.  The r option also generates EPROM files, but the data is 
  155. in a nonstandard bit shuffled format.  The o option produces an 
  156. ascii/hex output file named filename.ols.  The x option generates a 
  157. definition file named filename.x which can be used by other programs 
  158. to access words and variables in the compiled program.  The s option 
  159. prints a symbol table into filename.sym.  The d option turns on the 
  160. conditional compilation.  The i option specifies a directory for 
  161. include files.  Finally, the t option specifies a directory for 
  162. temporary files.
  163.  
  164.  
  165.  
  166. The l option generates an object code listing along with the 
  167. corresponding FORTH source code.  This allows the programmer to check 
  168. how well the code was optimized.  Often a fc listing file will include 
  169. a single line with thirty-two bits of code.  This is done for long 
  170. literal instructions (which are 32 bits long) and when optimizations 
  171. bail-out due to a missing key instruction (often an alu operation, 
  172. fetch, or store).  The listing file also includes any error messages.
  173.  
  174.    
  175.  
  176. The e option generates object code for hi and low byte EPROMs.  
  177. The output format is ASCII/HEX compatible with DATAIO format 51 (or 
  178. 56) and is produced only if no errors occurred during compilation.  
  179. This format consists of a start code, one or more address declarations 
  180. and data blocks, followed by a  stop code and checksum.  After 
  181. compilation, fc will query the user for the EPROM base address.  This 
  182. address is subtracted from the code address to produce an EPROM 
  183. relative address for output files. (If EPROMs are at 0x8000 hex, and 
  184. code starts at 0x8a00, the EPROM files would have address 0xa00 hex)  
  185. The r option generates the same type of files except the data for each 
  186. byte is bit reversed. 
  187.  
  188.  
  189.  
  190. The o option generates object code in an ascii/hex format that 
  191. is compatible with the load block format described later.  Each 16 bit 
  192. entity in the output file is represented by a four digit hexadecimal 
  193. number.  The format consists of a configuration number (equal to the 
  194. compiler version), start address, data word count, control checksum, 
  195. object code, and block checksum.  As with the other output formats, 
  196. code is only produced if there are no compilation errors.  
  197.  
  198.  
  199.  
  200. The x option produces a file with information about the symbols 
  201. used in the program.  This information includes the address of all 
  202. defined words and variables that are preceeded with the "xlink" label.  
  203. The "xcode" and "xheap" labels will cause the next available address 
  204. for code and/or variable allocation to be written to the file.  The 
  205. information is provided in a form that is compatible with fc.  That 
  206. is, another fc program can use a #include directive and include this 
  207. file and reference all the words and variables qualified with "xlink" 
  208. in the original program.  If the xcode and xheap qualifiers are used 
  209. in the original program, any new variables and code produced will fit 
  210. continuously with those produced by the first program.  This allows 
  211. programs to be compiled a piece at a time.  For example, some code 
  212. could be developed for EPROM and some for RAM.  The code developed for 
  213. RAM could use this feature to call routines in EPROM.
  214.  
  215.  
  216.  
  217. The s option produces a file containing the symbol table.  Each 
  218. symbol is listed along with its hexadecimal value.  A '*' is used to 
  219. indicate words and variables that are qualified with the "xlink" 
  220. label.
  221.  
  222.  
  223.  
  224. The d option compiles all lines in the input that start with a 
  225. '#' followed by a space.  Normally these lines are ignored if the d 
  226. option is not specified.  This allows debug code to be inserted into a 
  227. program  conditionally depending on if the d option is specified at 
  228. compile time.
  229.  
  230.  
  231.  
  232. The i option specifies a directory to be searched for include 
  233. files.  The directory name should immediately follow the i without any 
  234. spaces.  
  235.  
  236.  
  237.  
  238. The t option specifies a directory for temporary files.  The 
  239. directory name should immediately follow the t without any spaces.
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247. Environment
  248.  
  249.  
  250.  
  251. fc supports two environment variables, FC_TEMP and FC_INCLUDE.  
  252. These environment variables define the path names for temporary fils 
  253. and include files respectively. Unfortunately with the AMIGA version, 
  254. the variables must be set using the Aztec "set" command supplied with 
  255. the compiler instead of the environment commands provided with 
  256. AmigaDos 1.3.  
  257.  
  258.  
  259.  
  260. Setting the environment variables is not required but, can make 
  261. development more convenient and faster.  The FC_TEMP variable should 
  262. be set to a directory on either the hard disk or ram disk.  If this 
  263. variable is not set, temporary files will be written to the current 
  264. working directory.  The FC_INCLUDE directory can be set to a directory 
  265. containing a collection of include files.  This directory will be 
  266. searched for an include file if it can not be found in the current 
  267. working directory.   
  268.  
  269.  
  270.  
  271. If an include search directory is specified with the i option, 
  272. it will override the directory specified by the FC_INCLUDE environment 
  273. variable.  Also if a temporary file directory is specified with the t 
  274. option, it will override the directory specified by the FC_TEMP 
  275. environment variable.
  276.  
  277.  
  278.  
  279.  
  280.  
  281. fc Preprocessor
  282.  
  283.  
  284.  
  285. When fc is invoked, it processes the input file through a 
  286. preprocessor that expands all include files and macros and produces a 
  287. temporary file used for input to the compiler.  The preprocessor also 
  288. supports the conditional compilation and removes comments and inserts 
  289. filename/line number stamps used as reference for producing error 
  290. messages.  The preprocessor reserves the '#' character for specifying 
  291. commands and conditional compilation.  
  292.  
  293.  
  294.  
  295. The preprocessor has two commands -- one for including files 
  296. and another for macro definitions.  Either command must start in 
  297. column one and the keyword (include or macro) must be in lower case 
  298. letters. The entire command must fit on a single line.    
  299.  
  300.  
  301.  
  302. The include file inserts the contents of another file into the 
  303. program.  The filename follows "#include " and must not have any 
  304. spaces and may be qualified to access files outside the current 
  305. directory.  The current directory is searched for the file.  If it is 
  306. not found, the directory specified by the i option or the FC_INCLUDE 
  307. environment variable is searched.  
  308.  
  309.  
  310.  
  311. The macro command takes the first text following #macro as the 
  312. macro name and the remainder of the line as the replacement text.  
  313. From then on, whenever the macro name is encountered, the replacement 
  314. text is substituted.  Macro substitutions are case sensitive. Text 
  315. enclosed in double quotes and macro replacement text is not is not 
  316. searched for macros.
  317.  
  318.  
  319.  
  320. Examples of the include and macro commands:
  321.  
  322.  
  323.  
  324. #include filename
  325.  
  326. #macro  name  replacement text
  327.  
  328.  
  329.  
  330. #include monitor.x
  331.  
  332. #macro nip swap drop
  333.  
  334.  
  335.  
  336. Comments start with a '(' character and end with the 
  337. corresponding ')'.  Any number of matched pairs of '(' and ')' may 
  338. appear within a comment.  Comments may not begin or end on a line with 
  339. a #macro command.     
  340.  
  341.  
  342.  
  343. Macros and include files are used to extend the capabilities of 
  344. the fc compiler.  For example, fc does not directly recognize the 
  345. RTX2000 register instructions such as pc@, mr!, r>, yet these 
  346. instruction are easily added through the use of macros. Code libraries 
  347. and files filled with standard macros can be developed and accessed 
  348. easily with the include command.  The i option or the FC_INCLUDE 
  349. environment variable allows a single directory to be set up as a 
  350. repository of macro definitions and code libraries.
  351.  
  352.  
  353.  
  354. In addition to supporting include and macro, the '#' character 
  355. is also used to support conditional compilation.  A line in a source 
  356. file can be made conditional by inserting a '#' as the first character 
  357. of the line.  At least one space or tab should follow the '#' before 
  358. any of the source code.  If the program is compiled with the d option, 
  359. the conditional lines are included in the program.  If it is compiled 
  360. without the d option, the conditional lines are not included in the 
  361. program.
  362.  
  363.  
  364.  
  365.  
  366.  
  367. fc Memory Allocation
  368.  
  369.  
  370.  
  371. The RTX2000 uses absolute addressing for branches and variable 
  372. reference and the compiler fixes the code and variable locations at 
  373. compile time.  Code is compiled starting at a user defined address 
  374. (defaults to zero) and grows into higher memory.  Variables are stored 
  375. in an area referred to as the heap which starts in high memory and 
  376. grows downward into low memory.  The heap starting point can also be 
  377. defined (defaults to 10000 hex).  When a variable is defined, the 
  378. current heap value is decremented (once for characters, twice for 
  379. words) to provide the variable address.  (Variable allocation also 
  380. assures that all 16 bit variables are assigned even addresses.)
  381.  
  382.  
  383.  
  384. Typically the program starting address is assigned to the 
  385. lowest available memory address and the initial heap value is set to 
  386. one plus the highest memory address.  fc does not support paged memory 
  387. so all variables and code are limited to a single 64K byte page.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393. Reserved Words and Characters
  394.  
  395.  
  396.  
  397. The words listed below are recognized by the compiler as being 
  398. special and can not be used as word or variables names.  These words 
  399. also correspond to the operations supported by the compiler.
  400.  
  401.  
  402.  
  403. ; : ) code heap constant variable cvariable array carray 
  404.  
  405. xvariable xword nop ucode again begin drop dup else if dup?_if 
  406.  
  407. next over repeat swap then until while nop exit not of( 0< 2* 
  408.  
  409. 2*c cU2/ c2/ U2/ 2/ N2* N2*c D2* D2*c cUD2/ cD2/ UD2* D2/ + - 
  410.  
  411. and or xor nor nand +c -c xnor g@ g! u@ u! c@ c! @ ! @+
  412.  
  413. @- c@+ c@- !+ c!+ !- c!- ['] , { } byte word xcode xheap xlink
  414.  
  415.  
  416.  
  417.  
  418.  
  419. The '#' character is reserved for use by preprocessor commands, 
  420. conditional compilation, and as a character inside a string 
  421. definition.  The '"' character is reserved for strings and should not 
  422. be used in word and variable definitions.    
  423.  
  424.  
  425.  
  426.  
  427.  
  428. Numbers and Strings 
  429.  
  430.  
  431.  
  432. fc recognizes base 10 and base 16 (hex) numbers.  Numbers 
  433. preceeded by 0x are assumed to be hex and all other numbers are 
  434. assumed to be base ten.
  435.  
  436.  
  437.  
  438. fc also recognizes strings.  Strings may be included in word 
  439. definitions and must be enclosed by double quotes ("  ").  Within the 
  440. source file, strings may not extend over more then one line of the 
  441. source file text.  Special characters may be imbedded into strings by 
  442. using the following codes:
  443.  
  444.  
  445.  
  446.          \n        Carriage Return, Linefeed
  447.  
  448.          \t        Tab character
  449.  
  450.          \b        Backspace character
  451.  
  452.          \r        Carriage Return
  453.  
  454.          \f        Form Feed
  455.  
  456.          \\        Backslash
  457.  
  458.          \"        Double quote
  459.  
  460.  
  461.  
  462.  
  463.  
  464. Word, Variable and Constant names
  465.  
  466.  
  467.  
  468. fc supports user defined names as long as 32 characters. In 
  469. general, all names should start with a non numeric character and be 
  470. kept to 20 characters or less.  As a special case, names can start 
  471. with number provided that the second character is not a number or an 
  472. 'x' or 'X'.
  473.  
  474.  
  475.  
  476.  
  477.  
  478. fc Syntax
  479.  
  480.  
  481.  
  482. An fc program consists of memory definitions, variable 
  483. definitions, constant definitions, data definitions, x list control, 
  484. and word definitions. 
  485.  
  486.  
  487.  
  488. Memory definitions tell the compiler where to place code and 
  489. variables.  They have the form:
  490.  
  491.  
  492.  
  493. number CODE  ( sets next code output to address = number )
  494.  
  495. number HEAP  ( sets heap = number )
  496.  
  497.  
  498.  
  499. The program may have any number of code and heap definitions, 
  500. but typically there will be only one heap definition and code 
  501. definitions will be used at the start of the program and when words 
  502. have to be compiled to specific addresses (like interrupt routines).  
  503. fc is very stupid and will allow you to overwrite code and variables 
  504. without the slightest warning so, be careful.  Note that for each code 
  505. definition, fc will start a new output section.  
  506.  
  507.  
  508.  
  509. Variable definitions tell the compiler to allocate memory for 
  510. variables and arrays.  They have the form:
  511.  
  512.  
  513.  
  514. VARIABLE name  ( declares name as a variable and allocates 1 word )
  515.  
  516. CVARIABLE name  ( same as above but, allocates 1 byte )
  517.  
  518. number XVARIABLE name (assumes a variable name is at address = number)
  519.  
  520. number ARRAY name ( declares and allocates number words for name )
  521.  
  522. number CARRAY name ( declares and allocates number bytes for name ) 
  523.  
  524.  
  525.  
  526. The only difference between these definitions is the amount of 
  527. memory allocated.  Once a variable is declared and allocated, fc knows 
  528. no difference between a cvariable, variable, array, carray, or 
  529. xvariable.  The programmer is responsible for insuring that each 
  530. variable has the proper allocation for any operations performed in the 
  531. program.  
  532.  
  533.  
  534.  
  535. Constant definitions tell the compiler about different kinds of 
  536. constants that can be used.  They have the form:
  537.  
  538.  
  539.  
  540. number CONSTANT name ( declare name as a constant = number )
  541.  
  542. number XWORD name ( declare name as a word at address = number )
  543.  
  544. number UCODE name { declare name as a machine instruction = number )
  545.  
  546.  
  547.  
  548. Constant definitions allow the user to use symbolic names in 
  549. place of actual numbers.  Whenever a constant is encountered in a 
  550. FORTH word definition, fc will generate code to push its declared 
  551. value onto the parameter stack.  Whenever a xword is encountered, fc 
  552. will generate code for a subroutine call to the declared address.  
  553. When a ucode is encountered, the declared value is substituted 
  554. directly as a machine instruction.    
  555.  
  556.  
  557.  
  558. Data definitions tell the compiler to place tables of words or 
  559. bytes into memory for use by programs.  They have the form:
  560.  
  561.  
  562.  
  563. WORD name { datalist }  ( place datalist into memory as words )
  564.  
  565. BYTE name { datalist }  ( place datalist into memory as bytes )
  566.  
  567.  
  568.  
  569. where datalist is a list of constants separated by one or more spaces 
  570. and enclosed in braces.  In the case of a WORD table, the datalist may 
  571. also include variable names or word names.  (Variables must be 
  572. declared before they are included in the list)  In these cases, the 
  573. address of the variable or word is placed in the list.  For both word 
  574. and byte tables, the table name may be used by a program to push the 
  575. address of the table onto the stack (just like a variable name). 
  576.  
  577.  
  578.  
  579. X list control words control generation of the link file that 
  580. is generated when fc is invoked with the -x option.  The link file is 
  581. refered to as a .x file (its filename is sourcefilename".x").  The x 
  582. list control words appear below:
  583.  
  584.  
  585.  
  586. XCODE  ( causes a CODE statement to be printed in the .x file )
  587.  
  588. XHEAP  ( causes a HEAP statement to be printed in the .x file )
  589.  
  590. XLINK  ( causes the next defined symbol* to be printed in the .x file)
  591.  
  592.          *symbol should be a word, variable, or data definition
  593.  
  594.  
  595.  
  596. When XCODE appears in the source file, the .x file will contain 
  597. a CODE statement that defines code start at the next available 
  598. location when compilation finished.  When XHEAP appears in the source 
  599. file, the .x file will contain a HEAP statement that defines the heap 
  600. as the next available memory location when compilation finished.  When 
  601. XLINK appears before a word, variable, or data definition, it causes 
  602. the address of the following symbol to be included into the .x file as 
  603. an XWORD or XVARIABLE definition. 
  604.  
  605.  
  606.  
  607. The x list control words should be used outside word and data 
  608. definition.  The XCODE and XHEAP words need only appear once in a file 
  609. to generate the CODE and HEAP statements in the .x file.  The XLINK 
  610. word will typically appear immediately before the definition of the 
  611. word, variable, or data definition to be installed in the .x file.
  612.  
  613.       
  614.  
  615. Word definitions have the same format as standard FORTH words.  
  616. They start with a colon followed by the word name, a body of 
  617. statements, and end with a semicolon.  Word definitions do not have to 
  618. be ordered in a source file since words may be called before they are 
  619. defined.  
  620.  
  621.  
  622.  
  623. fc recognizes only a small number of basic FORTH words (called 
  624. statements here) summarized below:
  625.  
  626.  
  627.  
  628. if ..statements.. then
  629.  
  630. if ..statements.. else ..statements.. then
  631.  
  632. ?dup_if ..statements.. then
  633.  
  634. ?dup_if ..statements.. else ..statements.. then
  635.  
  636. for ..statements.. next
  637.  
  638. begin ..statements.. again
  639.  
  640. begin ..statements.. until
  641.  
  642. begin ..statements.. while ..statements.. repeat
  643.  
  644. exit      ( return to calling word )
  645.  
  646. drop
  647.  
  648. swap    
  649.  
  650. dup
  651.  
  652. over
  653.  
  654. nop                            ( no operation )
  655.  
  656. not                            (ones complement )
  657.  
  658. + - +c -c xnor nand xor or     ( alu operations )
  659.  
  660. g@                             ( fetch from RTX2000 ASIC bus )
  661.  
  662. g!                             ( store to RTX2000 ASIC bus )
  663.  
  664. u@                     ( fetch from RTX2000 user memory space )
  665.  
  666. u!                     ( store to RTX2000 user memory space )
  667.  
  668. c@ c! @ !                ( character and word fetch and store )
  669.  
  670. @+ c@+ @- c@-  ( character/word fetch with auto increment/dec )
  671.  
  672. !+ c!+ !- c!- ( character/word store with auto inc/decrement )
  673.  
  674. 0<  2*  2*c       ( shift instructions )
  675.  
  676. cU2/ c2/ U2/    
  677.  
  678. 2/ N2* N2*c D2* 
  679.  
  680. D2*c cUD2/ cD2/ 
  681.  
  682. UD2* D2/ 
  683.  
  684. of(            ( indicates RTX2000 streamed instruction ) 
  685.  
  686. [']            ( pushes address of following word onto stack )
  687.  
  688. "text"   ( defines string, pushes string address onto stack )
  689.  
  690. ,          ( causes immediate code production )
  691.  
  692.  
  693.  
  694. Many statements are compatible with the simple words in the 
  695. FORTH-83 standard.  The compiler also supports RTX2000 specific 
  696. instructions, such as streamed instructions using OF( (a closing right 
  697. parenthesis must be included to define the end of the streamed 
  698. instruction) and u!, u@, g!, and g@ memory and ASIC bus access 
  699. statements. fc also supports all the RTX2000 shift instructions.  (See 
  700. RTX2000 data sheet or Programmer's Reference Manual from Harris)  Also 
  701. supported is the comma operator which causes the compiler to start a 
  702. new RTX machine instruction with the statement that follows.  This 
  703. feature is sometimes useful for writing optimized programs.  Many 
  704. simple FORTH words are easily generated using macros.  See 
  705. accompanying programs for examples.
  706.  
  707.  
  708.  
  709. Most RTX2000 compilers and interpreters directly support a 
  710. number of RTX2000 specific words for manipulating registers on the 
  711. processor's internal ASIC bus.  These words are not directly supported 
  712. by fc, however, the macro feature allows programmers to define macros 
  713. for these instructions.  Typically a file filled with these 
  714. definitions can be referenced using an include command in the program 
  715. source file.  Likewise, support for RTX2010 features can be added 
  716. using macro commands. 
  717.  
  718.  
  719.  
  720. The basic statements (words) supported by the compiler are 
  721. described below.  Stack diagrams are also provided to show the state 
  722. of the parameter stack before and after execution of the statement.
  723.  
  724.  
  725.  
  726.  
  727.  
  728. if ..statements.. then
  729.  
  730. The top value of the parameter stack is popped and evaluated.  
  731. If the value is nonzero ..statements.. are executed.   
  732.  
  733.  
  734.  
  735. if ..statementsA.. else ..statementsB.. then
  736.  
  737. The top value of the parameter stack is popped and evaluated.  
  738. If the value if nonzero, ..statementsA.. are executed, otherwise 
  739. ..statementsB.. are executed.
  740.  
  741.  
  742.  
  743. ?dup_if ..statements.. then
  744.  
  745. If the top value of the parameter stack is nonzero, then 
  746. ..statements.. are executed.  Otherwise, the stack is popped and 
  747. discarded.
  748.  
  749.  
  750.  
  751. ?dup_if ..statementsA.. else ..statementsB.. then
  752.  
  753. If the top value of the parameter stack is nonzero, then 
  754. ..statementsA.. are executed.  Otherwise, the stack is popped, the 
  755. zero is discarded, and ..statementsB.. are executed.
  756.  
  757.  
  758.  
  759. begin ..statements.. again
  760.  
  761. Executes ..statements.. again and again in an endless loop.
  762.  
  763.  
  764.  
  765. begin ..statements.. until
  766.  
  767. ..statements.. are executed.  The top of the parameter stack is 
  768. popped by "until" and evaluated.  If the value is nonzero, execution 
  769. continues with the statement following "until", otherwise 
  770. ..statements.. are executed again.  
  771.  
  772.  
  773.  
  774. begin ..statementsA.. while ..statementsB.. repeat
  775.  
  776. ..statementsA.. are executed, then "while" pops the top of the 
  777. parameter stack.  If the value is zero, statements after repeat are 
  778. executed, otherwise ..statementsB.. are executed then..statementsA.. 
  779. are executed again and the "while" test is performed again.
  780.  
  781.  
  782.  
  783. exit ( -- )      
  784.  
  785. Execution is returned to the calling word.
  786.  
  787.  
  788.  
  789. drop  ( x -- )
  790.  
  791. The top of the parameter stack is popped and discarded.
  792.  
  793.  
  794.  
  795. swap  ( x y -- y x )
  796.  
  797. The top two items on the parameter stack are exchanged.  
  798.  
  799.     
  800.  
  801. dup  ( x -- x x )
  802.  
  803. The top value of the parameter stack is copied and pushed onto 
  804. the parameter stack.
  805.  
  806.  
  807.  
  808. over  ( x y -- x y x )
  809.  
  810. The second value of the parameter stack is copied and pushed 
  811. onto the parameter stack.
  812.  
  813.  
  814.  
  815. nop  ( -- )                          
  816.  
  817. No operation is performed.  
  818.  
  819.  
  820.  
  821. not  ( x -- y )                           
  822.  
  823. The top of the parameter stack is replaced by its ones 
  824. complement, y = not(x).
  825.  
  826.  
  827.  
  828. +  ( a b -- c )
  829.  
  830. The top two items on the parameter stack are replaced by their 
  831. sum, c = a + b.
  832.  
  833.  
  834.  
  835. -   ( a b -- c )
  836.  
  837. The top two items on the parameter stack are replaced by their 
  838. difference, c = a - b.
  839.  
  840.  
  841.  
  842.  
  843.  
  844. +c  ( a b -- c )
  845.  
  846. The top two items on the parameter stack are replaced by their 
  847. sum plus the value of the carry bit, c = a + b + carry bit.
  848.  
  849.  
  850.  
  851. -c  ( a b -- c )
  852.  
  853. The top two items on the parameter stack are replaced by their 
  854. difference minus the ones complement of the carry bit, c = a - b - 
  855. not(carry).
  856.  
  857.  
  858.  
  859. xnor ( a b -- c )
  860.  
  861. The top two items on the parameter stack are replaced by the 
  862. result of a logical exclusive nor operation, c = a xnor b.
  863.  
  864.  
  865.  
  866. nand ( a b -- c )
  867.  
  868. The top two items on the parameter stack are replaced by the 
  869. result of a logical nand operation, c = a nand b.
  870.  
  871.  
  872.  
  873. xor ( a b -- c )
  874.  
  875. The top two items on the parameter stack are replaced by the 
  876. result of a logical exclusive or operation, c = a xor b.
  877.  
  878.  
  879.  
  880. or ( a b -- c )
  881.  
  882. The top two items on the parameter stack are replaced by the 
  883. result of a logical or operation, c = a or b.
  884.  
  885.  
  886.  
  887. g g@  ( -- x )
  888.  
  889. Fetches word x from address g on the processor's ASIC bus and 
  890. pushes onto parameter stack.  g is a constant between zero and thirty-
  891. one.  See RTX2000/RTX2010 data sheet for register assignments.  
  892.  
  893.                             
  894.  
  895. g g!  ( x -- )
  896.  
  897. Pops top of parameter stack and stores it into address g of the 
  898. processor's ASIC bus.  g is a constant between zero and thirty-one.  
  899. See RTX2000/RTX2010 data sheet for register assignments.
  900.  
  901.                             
  902.  
  903. u u@   ( -- x ) 
  904.  
  905. Fetches word x from user space address u and pushes onto the 
  906. parameter stack.  u is a constant between zero and thirty-one.                     
  907.  
  908.  
  909.  
  910. u u!   ( x -- )
  911.  
  912. Pops top of parameter stack and stores it into address u of the 
  913. user space.  u is a constant between zero and thirty-one.
  914.  
  915.  
  916.  
  917. @  ( a -- d )
  918.  
  919. Replaces the top of the parameter stack with a word fetched 
  920. from the address a.
  921.  
  922.  
  923.  
  924. c@  ( a -- d )
  925.  
  926. Replaces the top of the parameter stack with the byte fetched 
  927. from memory address a.
  928.  
  929.  
  930.  
  931. !   ( d a -- )
  932.  
  933. Pops two items from the top of the parameter stack and stores 
  934. word d into memory address a.
  935.  
  936.  
  937.  
  938. c!  ( d a -- )
  939.  
  940. Pops two items from the top of the parameter stack and stores 
  941. data d as a byte into memory address a.
  942.  
  943.  
  944.  
  945. @+ ( a -- d a+2 )      
  946.  
  947. Pop address a from top of parameter stack and fetch word d from 
  948. memory address a.  Push d and a+2 onto parameter stack. 
  949.  
  950.  
  951.  
  952. c@+  ( a -- d a+1 )
  953.  
  954. Pop address a from top of parameter stack and fetch byte d from 
  955. memory address a.  Push d and a+1 onto the parameter stack.
  956.  
  957.    
  958.  
  959. @- (a -- d a-2 )      
  960.  
  961. Pop address a from the top of the parameter stack and fetch 
  962. word d from memory address a.  Push d and a-2 onto the parameter 
  963. stack.   
  964.  
  965.  
  966.  
  967. c@-  ( a -- d a-1 )
  968.  
  969. Pop address a from the top of the parameter stack and fetch 
  970. byte d from memory address a.  Push d and a-1 onto the parameter 
  971. stack.
  972.  
  973.  
  974.  
  975. !+  ( d a -- a+2 )      
  976.  
  977. Pop top two items off the parameter stack.  Store word d into 
  978. memory address a then push value a+2 onto parameter stack.
  979.  
  980.  
  981.  
  982. c!+  ( d a -- a+1 )
  983.  
  984. Pop top two items off the parameter stack.  Store d as a byte 
  985. into memory address a then push value a+1 onto the parameter stack.  
  986.  
  987.  
  988.  
  989. !-  ( d a -- a-2 )      
  990.  
  991. Pop top two items off the parameter stack.  Store word d into 
  992. memory address a then push value a-2 onto the parameter stack.
  993.  
  994.  
  995.  
  996. c!-  ( d a -- a-1 )
  997.  
  998. Pop top two items off the parameter stack.  Store d into memory 
  999. address a as a byte, then push value a-1 onto the parameter stack.
  1000.  
  1001.  
  1002.  
  1003. 0<  ( a -- b )
  1004.  
  1005. The top of the parameter stack is replaced by a value obtained 
  1006. by extending the most significant bit to every bit in the word.
  1007.  
  1008.  
  1009.  
  1010. 2*  ( a -- b )
  1011.  
  1012. The top of the parameter stack is shifted left by one bit.  
  1013. Zero is shifted into the lsb and the msb is shifted into the carry 
  1014. bit.  
  1015.  
  1016.  
  1017.  
  1018. 2*c  ( a -- b )
  1019.  
  1020. The top of the parameter stack is shifted left by one bit.  The 
  1021. carry bit is shifted into the lsb and the msb is shifted into the 
  1022. carry bit. 
  1023.  
  1024.     
  1025.  
  1026. cU2/  ( a -- b )
  1027.  
  1028. The top of the parameter stack is shifted right by one bit.  
  1029. The carry bit is shifted into the msb and the lsb is discarded.  Carry  
  1030. bit is set to zero.
  1031.  
  1032.  
  1033.  
  1034. c2/  ( a -- b )
  1035.  
  1036. The top of the parameter stack is shifted right by one bit.  
  1037. The carry bit is shifted into the msb and the lsb is shifted into the 
  1038. carry bit.
  1039.  
  1040.  
  1041.  
  1042. U2/  ( a -- b )
  1043.  
  1044. The top of the parameter stack is shifted right by one bit.  
  1045. Zero is shifted into the msb and the lsb is discarded.  The carry bit 
  1046. is set to zero.
  1047.  
  1048.    
  1049.  
  1050. 2/   ( a -- b )
  1051.  
  1052. The top of the parameter stack is shifted right by one bit.  
  1053. The msb remains unchanged and the lsb is discarded.  The carry bit is 
  1054. set to the value of the msb.
  1055.  
  1056.  
  1057.  
  1058. N2*   ( a x -- b x )
  1059.  
  1060. The second value from the top of the parameter stack is shifted 
  1061. left by one bit. Zero is shifted into the lsb.  The carry bit is not 
  1062. changed.
  1063.  
  1064.  
  1065.  
  1066. N2*c    ( a x -- b x )
  1067.  
  1068. The second value from the top of the parameter stack is shifted 
  1069. left by one bit.  The carry bit is shifted into the lsb.  The carry 
  1070. bit is not changed.
  1071.  
  1072.  
  1073.  
  1074. D2*   ( a b -- c d )
  1075.  
  1076. The top two items on the parameter stack are shifted left one 
  1077. bit together as a thirty-two bit word. The msb of the top is shifted 
  1078. into the carry bit. Zero is shifted into the lsb of the second item.
  1079.  
  1080.   
  1081.  
  1082. D2*c   ( a b -- c d )
  1083.  
  1084. The top two items on the parameter stack are shifted left one 
  1085. bit together as a thirty-two bit word. The carry bit is shifted into 
  1086. the lsb of the second item and the msb of the top is shifted into the 
  1087. carry bit. 
  1088.  
  1089.  
  1090.  
  1091. cUD2/   ( a b -- c d ) 
  1092.  
  1093. The top two items on the parameter stack are shifted right one 
  1094. bit together as a thirty-two bit word. The carry bit is shifted into 
  1095. the msb of the top and the lsb of the second item is discarded.  The 
  1096. carry bit is set to zero.
  1097.  
  1098.  
  1099.  
  1100. cD2/   ( a b -- c d )
  1101.  
  1102. The top two items on the parameter stack are shifted right one 
  1103. bit together as a thirty-two bit word. The carry bit is shifted into 
  1104. msb of the top and the lsb of the second item is shifted into the 
  1105. carry.
  1106.  
  1107.  
  1108.  
  1109. UD2*  ( a b -- c d )
  1110.  
  1111. The top two items on the parameter stack are shifted right one 
  1112. bit together as a thirty-two bit word. Zero is shifted into the msb of 
  1113. the top and the lsb of the second item is discarded.  The carry bit is 
  1114. set to zero.
  1115.  
  1116.  
  1117.  
  1118. D2/   ( a b -- c d )
  1119.  
  1120. The top two items on the parameter stack are shifted right one 
  1121. bit together as a thirty-two bit word. The msb of the top remains 
  1122. unchanged and the lsb of the second item is discarded. The carry bit 
  1123. is set to the state of the msb of the top item.
  1124.  
  1125.  
  1126.  
  1127.  
  1128.  
  1129. for ...statements... next
  1130.  
  1131. "for" causes a loop count (n) to be popped off the parameter 
  1132. stack and ...statements... are executed n times.  The iteration count 
  1133. minus one can be obtained by reading the top value of the return stack 
  1134. (using r@).  ( Note: return instructions should not be executed inside 
  1135. for...next loops since the iteration count is stored on the return 
  1136. stack)
  1137.  
  1138.  
  1139.  
  1140. of(   ( n -- )
  1141.  
  1142. Indicates an instruction, or instructions should be repeated.  
  1143. A closing right parenthesis is required to indicate the range of 
  1144. instructions to be repeated.  The instruction, or instructions must 
  1145. compile into a single 16 bit RTX2000 machine instruction or an error 
  1146. will occur.  The repetition count, n, is popped off the parameter 
  1147. stack and the indicated instruction(s) are executed n + 1 times. 
  1148.  
  1149.  
  1150.  
  1151. ['] user_defined_word
  1152.  
  1153. When ['] proceeds a user defined word, the address of the word 
  1154. is pushed onto the parameter stack instead of word being called as a 
  1155. subroutine.  
  1156.  
  1157.  
  1158.  
  1159. "String Text"     ( -- a )
  1160.  
  1161. Pushes the address of the defined string onto the parameter 
  1162. stack.  The first byte of the string will be a count of the number of 
  1163. characters that follow.  (Assumes that the RTX2000 is configured for 
  1164. Motorola type byte addressing)  
  1165.  
  1166.  
  1167.  
  1168. ,          
  1169.  
  1170. Comma causes the compiler to start a new RTX2000 machine 
  1171. instruction with the statement that follows.  Commas allow programmers 
  1172. to explicitly show how a program or portion of a program should be 
  1173. partitioned into RTX2000 instructions.  This allows the user to 
  1174. directly control which statements are combined into RTX2000 
  1175. instructions.  Commas are used to force a desired optimization that 
  1176. the compiler may not be able to achieve without the help of the 
  1177. programmer.  This feature is useful when writing super optimized code 
  1178. when the programmer has a good understanding of the RTX2000 
  1179. instruction set. 
  1180.  
  1181.  
  1182.  
  1183.  
  1184.  
  1185. In addition to the statements (words) defined above, the 
  1186. program may refer to user defined variables and words.  All variables 
  1187. must be defined before they are used, fc assumes all undefined 
  1188. references to be subroutine calls (user defined words). Words do not 
  1189. have to be defined before they are used but must be defined somewhere 
  1190. in the program being compiled.
  1191.  
  1192.  
  1193.  
  1194. Comments may be placed anywhere in the program file and begin 
  1195. with a space or newline followed by a left parenthesis.  They may 
  1196. extend over several lines and matching pairs of parenthesis may be 
  1197. included inside comments.  A right parenthesis matching the left 
  1198. parenthesis that started the comment is used to end a comment.
  1199.  
  1200.  
  1201.  
  1202.  
  1203.  
  1204. fc Code Optimization
  1205.  
  1206.  
  1207.  
  1208. fc performs optimization at the source code level by collecting 
  1209. the greatest number of FORTH statements that fit into one of its 
  1210. syntax templates (coded using yacc).  Many of these templates 
  1211. correspond directly to single RTX2000 instructions while others 
  1212. provide a default path in case single instruction optimization can't 
  1213. be achieved.  As the compiler collects FORTH statements one at a time 
  1214. to fit to a given template, other templates must be available so that 
  1215. code can be produced at any point (such as if a call statement is 
  1216. encountered, which can not be combined with other statements).  The 
  1217. yacc generated parser insures that the longest template will be 
  1218. chosen, incorporating as many FORTH instruction as feasible (given a 
  1219. particular template list) into a single RTX2000 instruction. This 
  1220. approach does not necessarily produce the shortest RTX2000 program 
  1221. but, it is easy to code and allows easy incorporation of new 
  1222. optimizations.  
  1223.  
  1224.  
  1225.  
  1226. The comma operator can be used to force the compiler to abandon 
  1227. looking for additional statements to pack into the machine 
  1228. instruction.  The statements following the comma will always start a 
  1229. new RTX2000 machine instruction.  
  1230.  
  1231.  
  1232.  
  1233. fc incorporates limited single token look ahead in its lexical 
  1234. analyzer.  Whenever a short constant or a "swap" is encountered, it 
  1235. looks ahead to see what the next token is.  If a "u@", "u!", "g@", or 
  1236. "g!" follows a short constant, then the compiler must start a new 
  1237. instruction beginning with the short constant.  When a "swap" is 
  1238. encountered that proceeds an alu operation, it can be incorporated 
  1239. into the same instruction as the alu operation.  Also if a "swap" 
  1240. follows a "swap", both are ignored.  This processing allows the 
  1241. compiler to aggressively optimize out any number of swaps that might 
  1242. precede an alu operation.  
  1243.  
  1244.  
  1245.  
  1246.  
  1247.  
  1248. Default Object Code Format
  1249.  
  1250.  
  1251.  
  1252. Whenever fc is invoked without the e, r, or o option, and no 
  1253. errors have occurred during compilation, fc will produce an object 
  1254. file in the default format.  This format consists of a sequence of one 
  1255. or more sections of code.  Each section consists of a start address, a 
  1256. byte count, and RTX2000 instructions in binary format.  The compiler 
  1257. will produce a new section each time the code address is set using a 
  1258. "code" definition, and whenever a current section becomes longer then 
  1259. 1024 bytes.  The format of the default object code file appears below.  
  1260. Each data entity is stored as a sixteen bit word.
  1261.  
  1262.  
  1263.  
  1264.  
  1265.  
  1266.  
  1267.  
  1268. Number of Sections
  1269.  
  1270. Starting address of section #1
  1271.  
  1272. Number of bytes in section #1
  1273.  
  1274. Data for section #1
  1275.  
  1276. { Starting address of section #2 (if needed) }
  1277.  
  1278. { Number of bytes in section #2 (if needed) }
  1279.  
  1280. { Data for section #2 (if needed) }
  1281.  
  1282. ....
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. DMSP Load Block Code Format
  1291.  
  1292.  
  1293.  
  1294. Whenever fc is invoked with the o option and no compilation 
  1295. errors occur, code is produced in the DMSP Load Block Format.  This 
  1296. format consists of a series of 16 bit numbers represented in ascii/hex 
  1297. format.  Each code section produced by the compiler is packed into an 
  1298. independent load block and all load blocks are concatenated into a 
  1299. single file.  The output file format appears below.
  1300.  
  1301.  
  1302.  
  1303.  
  1304.  
  1305. Configuration Number
  1306.  
  1307. Start Address for section #1
  1308.  
  1309. Data Word Count for section #1
  1310.  
  1311. Control Checksum for section #1 header
  1312.  
  1313. Data for section #1
  1314.  
  1315. Block checksum for section #1
  1316.  
  1317. { Configuration Number for section #2 (if needed)}
  1318.  
  1319. { Start Address for section #2 (if needed) }
  1320.  
  1321. { Data Word Count for section #2 (if needed) }
  1322.  
  1323. { Control Checksum for section #2 (if needed) }
  1324.  
  1325. { Data for section #2 (if needed) }
  1326.  
  1327. { Block checksum for section #2 (if needed) }
  1328.  
  1329. ....
  1330.  
  1331.  
  1332.  
  1333. The configuration number for each load block will equal the 
  1334. compiler version  (for version 1.13, the configuration number = 000D 
  1335. (hex)).  The checksum algorithm is add and rotate 1 bit right.  The 
  1336. header checksum consists of the first three words in a block - the 
  1337. configuration number, the start address, and the word count.  The 
  1338. block checksum covers the configuration number, the start address, the 
  1339. word count, the control checksum, and all the data.
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345. Error Messages
  1346.  
  1347.  
  1348.  
  1349. fc produces a limited number of rather general error messages.  
  1350. All error messages, except for undefined word, are accompanied with 
  1351. file name, line number, and text from the vicinity of the error.  
  1352. After an error has occurred, the compiler continues until it completes 
  1353. the file.  When an error occurs within a word definition, the compiler 
  1354. may skip over nearby errors and not report them.  All errors will be 
  1355. included in the list file if the l option is specified. 
  1356.  
  1357.  
  1358.  
  1359. A missing colon in a word definition may cause the compiler to 
  1360. print out a lot of "invalid statement" errors, one for each label 
  1361. encountered in the word definition. 
  1362.  
  1363.  
  1364.  
  1365.  
  1366.  
  1367. Limitations
  1368.  
  1369.  
  1370.  
  1371. fc stores generated code internally in a fixed size buffer.  
  1372. Because of the defined length of the buffer, all programs should be 
  1373. limited to 20K - 25K bytes or shorter.
  1374.  
  1375.  
  1376.  
  1377.  
  1378.  
  1379. Revision History
  1380.  
  1381.  
  1382.  
  1383. fc version 1.3 is the first version with intentional 
  1384. distribution, however a short history of revision is given below:
  1385.  
  1386.  
  1387.  
  1388. 1.2   First revision with all EPROM output options
  1389.  
  1390. 1.2a  Bug in l option fixed, l option no longer hangs up the  
  1391.  
  1392.       program for outputs that start with indented lines.
  1393.  
  1394. 1.3   DMSP output option added.
  1395.  
  1396. 1.4   var keyword changed to variable
  1397.  
  1398.       cvar keyword changed to cvariable
  1399.  
  1400.       xvar keyword changed to xvariable
  1401.  
  1402.       inline keyword changed to ucode
  1403.  
  1404.       return keyword changed to exit
  1405.  
  1406.       To increase compatibility with Harris TFORTH compiler
  1407.  
  1408.       Bug fix in parser to support heap definition of 0x10000
  1409.  
  1410. 1.5   ['] word added
  1411.  
  1412.       String support added
  1413.  
  1414. 1.5a  IBM only - bug in string support fixed
  1415.  
  1416. 1.5b  IBM only - bug in ['] fixed
  1417.  
  1418. 1.6   DMSP option changed so that there are no spaces in file
  1419.  
  1420.       Configuration number for this option is set to zero               
  1421.  
  1422.       instead of being prompted from the user
  1423.  
  1424. 1.7   Fixed disassembly output for DUP d g! instructions
  1425.  
  1426.       Added comma feature
  1427.  
  1428.       Added word and byte data definitions
  1429.  
  1430. 1.8   Corrected bug with instructions of the form DUP d alu-op
  1431.  
  1432.       Changed configuration word to equal the complier version
  1433.  
  1434. 1.9   Corrected bug with DMSP block load checksum
  1435.  
  1436.       Printout size of each output section
  1437.  
  1438.       Modified preprocessor so that strings are ignored
  1439.  
  1440.         in macro substitutions
  1441.  
  1442. 1.10  Fixed bug with constants used in "word" statements
  1443.  
  1444.       Fixed preprocessor so that #, (, and ) may be used in                 
  1445.  
  1446.          strings 
  1447.  
  1448.       Added xheap, xcode, and xlink statements
  1449.  
  1450.       Added -s option
  1451.  
  1452. 1.11  Fixed bug with @- and c@- instructions
  1453.  
  1454.       Filename extensions allowed for source files
  1455.  
  1456. 1.12  Added optimization for longlit OVER alu-op instruction
  1457.  
  1458.       Added environment variables
  1459.  
  1460.       Added conditional compilation
  1461.  
  1462.       Fixed bug with disassembly of d g@ OVER alu-op 
  1463.  
  1464.       Changed command line print-out for code production
  1465.  
  1466. 1.13  Speeded up preprocessor and symbol table  
  1467.  
  1468.       Added optimization for DUP d u@ aluop instruction
  1469.  
  1470.       Allows use for larger programs
  1471.  
  1472.       Added -i -t options
  1473.  
  1474. 1.14  MS Windows Version (wfc)
  1475.  
  1476.       Trialing '\' character no longer needed for specifing
  1477.       path using envirnment variables
  1478.  
  1479.       No longer prompts user to stop after set number of errors
  1480.  
  1481.  
  1482.  
  1483.  
  1484.  
  1485. References
  1486.  
  1487.  
  1488.  
  1489. The second reference is an excellent general reference for 
  1490. scientific computing which also contains some search and sorting 
  1491. algorithms.  The other three references provide a good practical 
  1492. introduction to compiler writing using coded examples.
  1493.  
  1494.   
  1495.  
  1496. Aho, A, V,, Sethi, R., and Ullman, J., D., Compilers 
  1497. Principles, Techniques, and Tools, Addison-Wesley Publishing, 
  1498. Massachusetts, 1988.
  1499.  
  1500.  
  1501.  
  1502. Flannery, B. P., Press, W. H., Teukolsky, S. A., and 
  1503. Vetterling, W. T., Numerical Recipes in C The Art of Scientific 
  1504. Computing, Cambridge University Press, New York, 1988.
  1505.  
  1506.  
  1507.  
  1508. Friedman, H. G. Jr., and Schreiner, A. T., Introduction to 
  1509. Compiler Construction with UNIX, Prentice-Hall, New Jersey, 1985.
  1510.  
  1511.  
  1512.  
  1513. Kernighan, B. W., and Pike, R., The Unix Programming 
  1514. Environment, Prentice-Hall, New Jersey, 1984.
  1515.  
  1516.  
  1517.  
  1518.  
  1519.  
  1520.  
  1521.  
  1522. Lloyd Linstrom
  1523.  
  1524. October 1992
  1525.  
  1526.  
  1527.  
  1528.  
  1529.  
  1530. 
  1531.